Autofix E2E Report — Issue #11409

Summary

The nightly release v0.23.1-nightly.20260908.1f890086f1 (run 34279240951) failed because the aggregated Quality Checks job failed closed: the Workspace Tests (2/3) lane exited non-zero while every other lane (static, build, typecheck, scripts, shards 1 and 3, both integration lanes) passed.

Root cause

Shard 2 ran a Web Shell unit test that could not execute in any environment:

FAIL App.test.tsx > App session callbacks > does not rerender App for other split sessions (outer pending: false)
ReferenceError: mockUseDaemonActivePromptBridge is not defined

This is a semantic merge conflict, not a product bug:

1. 6b7e5615c7 (fix(web-shell): show session active work #11267, landed 11:54 UTC) renamed the App-level hook useDaemonActivePromptBridge to useDaemonSessionActivityBridge on main, including its test mock mockUseDaemonSessionActivityBridge.
2. feat(web-shell): Improve split-view session navigation #11250 (squash-merged as 70cf363395 at 17:33 UTC) had been written against the old name. Its CI ran green on its own head, where the old name still existed.
3. The squash merge onto current main combined textually but left the PR's new test block referencing the deleted name. The 17:02 UTC preview release had already checked out an older commit, so the 21:12 UTC nightly was the first release validation to run the broken test.

The check-run annotations for the failed job show only GitHub's generic "Process completed with exit code 1" — consistent with run-release-workspace-tests.sh finding a real FAIL line (it stays silent in that case) rather than a Vitest transport timeout or an infrastructure death.

Fix

One test-only change in packages/web-shell/client/App.test.tsx (3 lines): the split-view rerender test now uses the existing, correctly named mockUseDaemonSessionActivityBridge mock. That mock wires useDaemonSessionActivityBridge, which App.tsx calls unconditionally on every render, so it is exactly the rerender sensor the test intends — the same hook the PR's sensor referenced under its pre-rename name.

A mutation probe confirms the repaired test still guards the behavior: with App.tsx temporarily changed so that foreign-session pending reports force a rerender, both variants of the test fail; with the code restored, they pass.

Two other failure groups appear only in this sandbox and are not part of the CI failure: ChannelBase.test.ts (EACCES creating ~/.qwen under a root-owned HOME) and exit-worktree.session.integ.test.ts both pass with a writable HOME, and the remaining first-attempt failures (docsCommand, extensionsCommand, Footer snapshots) were caused by this sandbox's SANDBOX/QWEN_* environment variables leaking into the test process.

Verification

• npm run lint:ci (pre-fix, release quality_static equivalent) — passed
• npm run typecheck (pre-fix) — passed
• npm run test:scripts (pre-fix, release quality_scripts equivalent) — 82 files, 2310 passed, 17 skipped
• npm run check:serve-fast-path-bundle (pre-fix) — passed
• npm run build (pre-fix) — passed
• npm run bundle + dist/review-sources.sha256 presence (pre-fix verify-package steps) — passed
• npm run prepare:package (pre-fix) — passed
• VITEST_RETRY=2 NO_COLOR=true .github/scripts/run-release-workspace-tests.sh 2 on the failing commit — reproduced: packages/web-shell App.test.tsx failed 2 tests with ReferenceError: mockUseDaemonActivePromptBridge is not defined
• Post-fix npx vitest run client/App.test.tsx -t "does not rerender App for other split sessions" (packages/web-shell) — 2 passed
• Post-fix full Web Shell suite npx vitest run --config vitest.config.ts — 288 files, 6712 tests, all passed
• Mutation probe on App.tsx (force rerender on every pending-panes report) — both repaired tests fail; after restoring, both pass
• Post-fix exact release lane VITEST_RETRY=2 NO_COLOR=true .github/scripts/run-release-workspace-tests.sh 2 — every workspace green (cli 341 files / 9627 tests, core 216 / 7275, web-shell 96 / 3020, channels/base 7 / 968, all others passed), exit code 0
• Post-fix npm run build — passed
• Post-fix npm run typecheck — passed
• Post-fix npm run lint — passed
• Pre-commit hook (lint-staged on the changed file) — passed

FAIL App.test.tsx > App session callbacks > does not rerender App for other split sessions (outer pending: false)
ReferenceError: mockUseDaemonActivePromptBridge is not defined

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.23.1

✅ Qwen Triage finished — CI landed green on 34e6ea3 and the deferred approval was posted. finalize run

✅ Qwen Triage 已完成 —— 34e6ea3 的 CI 全绿，延迟审批已提交。查看 finalize 运行

Thanks for the PR!

Template looks good ✓

Problem: observed, with a named failure — not hardening against a hypothetical. The nightly v0.23.1-nightly.20260908.1f890086f1 failed its aggregated Quality Checks gate (#11409). I confirmed the cause independently rather than taking the description's word for it: on main@1f890086f1, mockUseDaemonActivePromptBridge has no declaration anywhere in the repository — a repo-wide search returns exactly three hits, at packages/web-shell/client/App.test.tsx:28940, :28941 and :28944, which are precisely the three lines this PR changes. The test therefore dies with a ReferenceError before reaching a single assertion, so it cannot pass in any environment.

Direction: aligned. A test that cannot execute is failing the release gate, and repairing it is squarely in scope. There is no product surface here, so there is no upstream direction signal to weigh — I did not go looking for one.

Size: not applicable. No core paths: one file under packages/web-shell/client/, +3/−3, all of it test code, so 0 production logic lines. Stage 0 does not engage.

Approach: minimal, and as far as I can tell the only correct option. I pulled #11267's own diff (6b7e5615c7) to check the equivalence claim instead of trusting the description: that commit renamed this exact symbol in five other places in this same file — the vi.hoisted destructure, the vi.fn() factory, the vi.mock wiring, the top-level beforeEach reset plus its mockImplementation, and an toHaveBeenCalledWith assertion — and also renamed App.tsx's import and call site, and the hook definition itself. #11250 (70cf363395) merged five hours later carrying a new test block still written against the pre-rename name. So this PR is the same rename applied to the three lines #11267 could not see.

The alternative — reinstating a mock under the old name — would be wrong, not merely larger: the vi.mock factory for session-catalog/session-catalog-hooks no longer exports useDaemonActivePromptBridge at all, so a fresh mockUseDaemonActivePromptBridge would never be called and expect(...).toHaveBeenCalled() would fail instead. Nothing to cut, no drive-by edits, no formatting churn.

Risk: no elevated risk signals. The high-risk path scan has nothing to match — the only changed file is filtered out as a .test.tsx.

One non-blocking observation, explicitly not for this PR: the reason this reached main is that required checks run against a PR's pre-merge head, so a rename landing while a PR is open can yield a green PR that breaks the combined tree. The description correctly scopes that out. Is there appetite for a separate look at post-merge or merge-queue validation? That belongs in its own issue rather than widening this diff.

Moving on to code review. 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 34e6ea308ba672aab80d11242e0e4ef0feceb723 · re-run with @qwen-code /triage}

Code review

No critical blockers, and no AGENTS.md violations. Test-only, three lines, one symbol substituted — nothing unrelated rode along.

What I actually spent the time on is whether the replacement mock is the same sensor, since a rename that quietly changes what a test measures is worse than a test that fails loudly. My own baseline before judging the diff: for a test referencing a symbol a rename deleted, the options are (a) repoint the references at the surviving equivalent, (b) re-add a mock under the old name, (c) replace the sensor with an explicit render counter, or (d) drop the test. (b) is wrong here, (c) and (d) throw away or duplicate working machinery, so (a) is what I'd have done — and it is what the PR did.

I then verified the premises of (a) rather than assuming them:

• mockUseDaemonSessionActivityBridge is declared in the top-level vi.hoisted() block (App.test.tsx:250), so it is in module scope and resolves at line 28940 — the failure was a missing declaration, not a scoping or hoisting problem.
• The vi.mock('./session-catalog/session-catalog-hooks') factory maps useDaemonSessionActivityBridge to that mock (App.test.tsx:1625) and exports no useDaemonActivePromptBridge. That is why option (b) would not work: a fresh mock under the old name would never be called, and expect(...).toHaveBeenCalled() would fail instead of the ReferenceError.
• App.tsx:3304 calls useDaemonSessionActivityBridge(...) in the component body among the other hooks, so it fires on every App render.
• It is the only production caller of that hook outside its defining module. ChatPane.tsx uses the compatibility wrapper useDaemonActivePromptBridge, and App.tsx imports ChatPane as import type only (App.tsx:175), so ChatPane never renders in this suite and cannot trip the sensor. The mock is therefore App-exclusive, and not.toHaveBeenCalled() genuinely means "App did not re-render" — not "nothing anywhere re-rendered".
• The top-level beforeEach (App.test.tsx:9324) does mockReset() plus a mockImplementation (:9393–:9394), so the call count starts at zero for each variant and the clear-then-assert sequence is meaningful.

Net: the repaired test measures the same thing it was written to measure, and it is not vacuous — its own positive assertion at line 28940 fails loudly if the sensor ever stops firing, so a silently-dead sensor cannot pass.

Test evidence

This is an unattended CI run (GITHUB_EVENT_NAME=pull_request_target), so the evidence below is the PR's own CI read through the API. I did not build, run, or check out any PR-derived code — no vitest, no gh pr checkout, no scripts from the diff.

The lane that matters here does cover the change: Test (ubuntu-latest, Node 22.x) runs npm run test:ci:workspaces (ci.yml:764), which fans out to every workspace defining a test:ci script, and packages/web-shell defines one as vitest run --config vitest.config.ts (packages/web-shell/package.json:34). So a green Test lane is direct evidence that the two previously-broken variants execute and pass — not a proxy. Worth noting the lane that originally caught this bug, the release workflow's Workspace Tests (2/3), does not run on pull requests; the PR-CI Test lane is its equivalent coverage.

At the time of writing there are no failures: 9 checks succeeded, 13 skipped, 5 still running — including Test (ubuntu-latest, Node 22.x) and Lint & Static (ubuntu-latest, Node 22.x). I did not poll or sleep-wait on them (the unit suite outlasts any sensible in-agent wait); the Qwen Triage Finalize job rewrites the table below once CI settles. The skipped lanes — Test (macos-latest…), Test (windows-latest…), Integration Tests (CLI, No Sandbox), verify, tmux-testing — are skipped by this repo's PR classification, not red.

Final CI results for 34e6ea3 (auto-updated by the triage finalize job after CI completed):

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

Sandboxed verification would settle the one thing a green suite cannot: @qwen-code /verify — that the repaired test is load-bearing, i.e. that it fails again if App is changed to re-render on a foreign session's pending-panes report. The mutation probe supporting that claim is the author's, not something I re-ran, and a suite that passes identically with and without an assertion proves nothing. I rate this low-stakes rather than unimportant: the static chain above (App-exclusive sensor, called per render, reset per test, plus the test's own positive assertion) already makes a dead sensor impossible, so /verify would confirm what the structure implies.

Real-scenario tmux testing: N/A — unattended CI run, and nothing user-visible: the diff touches no product code, so there is no terminal surface to drive.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 34e6ea308ba672aab80d11242e0e4ef0feceb723 · re-run with @qwen-code /triage}

Confidence: 5/5 — clean at every stage; the only thing between this and merge is CI landing, which the deferred approval below handles.

Stepping back: this is the easy case that still deserves the hard look, because "obvious three-line test fix" is exactly where a silently-wrong repair sails through. The failure mode that matters for a rename repair is not "does it compile" — it is "does the test still measure what it claims to measure". I went looking for that specifically and it isn't present: the substituted mock is wired to the hook App calls on every render, nothing else in the suite can reach it, it is reset before each test, and the test's own positive assertion would fail loudly if the sensor ever went dead. So the repaired test is neither vacuous nor measuring something new.

The part I'd normally expect to go unchecked, and which turned out to be the interesting one: re-adding a mock under the old name — the "restore what was deleted" instinct — would have been affirmatively wrong here, not just larger, because the module mock no longer exports that hook name at all. Pulling #11267's diff settled it. That commit renamed this same symbol in five other places in this very file; these three lines arrived five hours later via #11250, which is why they were missed. The PR is the same rename completed, nothing more.

Everything in the diff is necessary: there are exactly three occurrences of the dead symbol in the entire repository and the PR changes exactly those three. No drive-by edits, no formatting churn, no scope creep. In six months this reads as a test that names the hook the code actually uses — I'd thank the author, not curse them.

Two honest caveats, neither blocking:

• I have not seen this run. Test (ubuntu-latest, Node 22.x) — the lane that executes the repaired file — was still in progress when I wrote this, and I did not poll it. My confidence rests on the static chain above plus the fact that the lane genuinely covers packages/web-shell; the green suite is what the deferred approval is waiting for.
• The mutation probe (that the test fails again if App is made to re-render on foreign-session reports) is the author's claim and I did not re-run it. I judged it structurally sound rather than independently confirmed, and named @qwen-code /verify in the Stage 2 comment as the lane that would close it.

On the gate's usual skepticism: I checked whether I was being worn down or being a pushover, and neither applies — this is one PR against one named failing release run (#11409), from the repo's own autofix pipeline, and I verified the problem exists myself instead of accepting the framing. A repo-wide search for the dead symbol returning three hits, all of them the changed lines, is about as direct as evidence gets.

What this PR deliberately does not do is prevent the next one: required checks ran green on #11250's pre-merge head while a rename landed on main underneath it, so the combined tree was never validated before the nightly hit it. That is a real recurring exposure and the description is right to scope it out of a release-unblocking fix — but it should not be dropped. A separate issue on post-merge or merge-queue validation is worth opening, and I've flagged it in the Stage 1 comment.

Approval is deferred until CI lands green on 34e6ea308ba672aab80d11242e0e4ef0feceb723; the finalize job posts the commit-pinned approval then, and withholds it if anything lands red or the head moves.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 34e6ea308ba672aab80d11242e0e4ef0feceb723 · re-run with @qwen-code /triage}

🖼️ web-shell visual preview

Rendered against a mock daemon (no real backend): the PR base vs this PR head 34e6ea3. Only screenshots that changed are shown (flows below, if any, are head-only) — refreshes on every push.

Screenshots · before / after

_{Full-resolution recordings (.webm) are attached to the workflow run.}

— Qwen Code · web-shell visuals

✅ AutoFix round 1 finished — view run. See this round's report below.

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix round — no action required

All feedback on this round was triaged; nothing required a code change.

Feedback triage

• [rv:5148347672] @qwen-code-ci-bot (COMMENTED) — "Partially reviewed — gaps disclosed."
  The automated reviewer's own ledger records zero findings ("findings":[]). The body only discloses review-coverage gaps from its tool budget (an unfinished mutation probe, and typecheck/lint/full-suite runs it did not perform). It requests no change, so there is nothing to implement. The gaps are about review depth, not about the PR: this PR is a 3-line, test-only rename (mockUseDaemonActivePromptBridge → mockUseDaemonSessionActivityBridge) in packages/web-shell/client/App.test.tsx, the renamed mock is used consistently throughout the file, and no stale references remain.

• [ic:5593126723] @qwen-code-ci-bot — web-shell visual preview.
  Informational screenshot-diff notice from the visual-preview workflow (rendered against a mock daemon). The PR touches only a .test.tsx file, which is not part of the web-shell bundle and cannot affect rendered output; the flagged terminal-turn-error-copy-narrow-dark frame is render noise from the mock-daemon comparison, not a regression introduced by this change.

Repository state

• CI checks on head 34e6ea3: all completed checks are SUCCESS (19) or SKIPPED (48); zero failures, and the "Failed checks" / "Still-red checks" sections are empty.
• A maintainer-bot review has already APPROVED the PR ("LGTM, looks ready to ship — CI landed green after the review. ✅").
• No inline review comments exist; no base-branch conflict resolution was requested.

No commit was made; the branch is unchanged.

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.23.1

Maintainer verification — real local environment

I built a real environment for this PR and ran it: a dedicated worktree at the PR head 34e6ea308b with its own npm ci and a full npm run build, Linux / Node v22.22.2. Every result below is a real vitest run in that worktree, not a reading of the diff.

Verdict: the change itself is correct, but merging it now is a no-op — please close it as superseded by #11406 rather than merging.

git merge-tree --write-tree origin/main 34e6ea308b produces 35a388f06e528fc920ea89394f01e71683f8531b, and git rev-parse origin/main^{tree} is the same hash. Merging this PR would change nothing on main, because #11406 (3a75f37ef5, merged 2026-09-09 00:10:49Z) already landed the identical substitution. Fixes #11409 also points at an issue that is already closed (01:13:34Z).

1. The break reproduces exactly, and the fix clears it

On the nightly tree 1f890086f1 the two variants fail with the exact ReferenceError from nightly job 102243304038. On the PR head they pass.

The PR's own full-suite claim holds, and it closes a caveat the PR could not: the full web-shell suite on the pre-fix tree is 1 failed | 287 passed (288) / 2 failed | 6710 passed (6712) — those two tests are the only failures in 6712, so this is the complete remedy for the red, not a partial one. PR head and current main are both 288 passed / 6712 passed.

2. This PR's version is strictly weaker than what main already has

Ten arms, each a real vitest run, crossing three versions of the test file with test-side and production-side mutants:

Arms 4 and 5 are the finding, and they close the gap the automated review disclosed (agent 6c: "mutation run of the unmodified test with rerender() removed"):

• This PR (arm 4): delete rerender() → 1 failed | 1 passed. One variant still passes, because the positive expect(...).toHaveBeenCalled() guard is satisfied by setup-time calls, not by the rerender.
• main (arm 5): delete rerender() → 2 failed, and the first failure is the positive guard (spy was NOT called). fix(web-shell): Replace undefined mock in split rerender tests (#11404) #11406's extra mockClear() line is what makes that guard measure the rerender.

A call-count census makes the mechanism explicit: at the positive guard this PR's version sees 6–7 recorded calls (only 1 of them the rerender), while main's version sees exactly 1.

Both versions do detect a genuine production regression — forcing App to rerender on every pending-pane report fails both variants in both versions (arms 8/9), and dropping the owner-session filter in handleSplitPendingPanesChange fails one variant in both (arms 6/7). So this PR is not broken; it is simply the weaker of two fixes for the same line, and main already has the stronger one.

3. Two notes on the escape narrative, for the record

a) main's own push lane caught this 2h36m before the nightly. The PR says the nightly "was the first release validation to execute the combined tree" — accurate as worded, but it may read as though nothing saw the break earlier. ci.yml does carry push: branches: [main]; the post-merge run 34257817936 on 70cf363395 started at 17:33:27Z and failed at 18:36:28Z (Test (ubuntu-latest, Node 22.x), job 102182712398) — which is what issue #11404 was filed from, and what #11406 was written against. The nightly at 21:12:10Z was the second signal, not the first.

b) So the CI gap is not a missing gate — it is an unactioned one. The PR scopes out "how a semantic merge conflict reached main" as CI machinery. Worth recording where the real gap sits: the post-merge signal exists and fired correctly; what is missing is anything that blocks a release on it. I confirmed no static gate can substitute — on the broken tree, tsc --noEmit -p packages/web-shell/tsconfig.json exits 0 (the tsconfig excludes client/**/*.test.tsx) and eslint on the file exits 0 (no-undef resolves to [0, {"typeof": false}]). Only running the test catches this class.

Recommendation

Close #11412 as already fixed by #11406. Merging is harmless (it is provably a no-op), but it adds nothing and the linked issue is already resolved. Had it merged first, it would have left the positive guard satisfiable by setup-time calls — the weaker of the two fixes.

Harness, raw logs for all ten arms, the three full-suite runs and the gate probes: assets-pr11412.

Follow-up: merged — nothing to undo, and one correction to my comment above

This landed as c3023b3e6d while the verification above was still running. No action is needed: the merge is an empty commit.

$ git rev-parse c3023b3e6d^{tree}     35a388f06e528fc920ea89394f01e71683f8531b
$ git rev-parse c3023b3e6d~1^{tree}   35a388f06e528fc920ea89394f01e71683f8531b

main is byte-identical before and after — exactly the merge-tree prediction. Nothing to revert (a revert of an empty commit is itself empty and would only add noise), and the stronger guard from #11406 — the extra mockClear() that makes the positive assertion measure the rerender rather than setup-time calls — is untouched. I re-ran the full suite on current main c069801657: 288 files / 6712 tests, all passing.

Correction to my comment above. I wrote that Fixes #11409 pointed at an issue that was "already closed". That was wrong about the cause: #11409 was closed at 01:13:34Z, one second after this merge at 01:13:33Z — it was closed by this PR, not independently beforehand. (#11406 closed #11404, the post-merge-CI issue; #11409 was the separate nightly-release issue and was still open.) This does not change anything else: the merge was still a no-op, and the fix that actually made #11409's test pass had already landed in #11406.

The one item still worth acting on is unrelated to this PR: the post-merge push lane went red on 70cf363395 at 18:36:28Z and nothing blocked the 21:12:10Z nightly on it. Happy to open a separate issue for that if useful.

$ git rev-parse c3023b3e6d^{tree}     35a388f06e528fc920ea89394f01e71683f8531b
$ git rev-parse c3023b3e6d~1^{tree}   35a388f06e528fc920ea89394f01e71683f8531b

Released in v0.23.2.